Recently, microservices have become a popular architecture to build modern Web services. By breaking down a complex monolithic application into small independent services it becomes possible to develop services that are more resilient to error and more scalable. For example, if a particular microservice would fail, it would not affect the entire service. However, if a component part of a monolithic service would fail, the entire service would have to be restarted. Also, the only way to scale a monolithic service is to duplicate the whole monolith by adding more instances of it. In a microservice based architecture on the other hand, only the services that need to be scaled need to be duplicated.
Software containers are commonly used to implement microservice-based architectures and make sure services can run independently of each other. In contrast to virtual machines, software containers are more lightweight and can instantly be started, similar to standard Unix processes, assuming the server has all images required to start the container. Another advantage is that software containers provide a reliable execution environment allowing developers to develop and test their services locally on their machine and then upload the image to a cloud platform and still be sure the containers behave similarly as running them locally.
Docker is an example of a container runtime that has recently gained popularity. By allowing container images to be stacked in a so-called union file system, container images can more efficiently be distributed.
However, when adopting a microservice based container architecture, designers and developers still need to figure out how to manage the life cycle of individual components, for example when to start a new service, when to scale it, how to handle fault recovery and so on.
Additionally, a general problem with current container based architectures is that it takes time to start new containers. This is particularly a problem when using cluster management platforms such as Apache Mesos where the start-up delay can vary from a couple of seconds up to several minutes depending if the selected server in the cluster already has the necessary container images required to start the container in local storage or not. Without taking precautionary actions, a fresh new server added to the cluster has typically no container images at all, and will thus cause a significant delay. Also, finding a suitable server in the cluster for running the container as well as starting it up adds to the delay.
From a user perspective, the service should start without noticeable delay or at least with acceptable delay. To give a perspective, a common practice is to minimize the size of JavaScript code loaded by Web browser to more quickly start a Web application. Waiting several minutes for deploying a container would in many cases not be a practical solution. Consequently, adopting a design principle where containers are started on demand would not be possible in such a case.